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Yom can apply the transaetion-ias^ recovery 
ameepi used in databases to my ^^iaOion, 
Doing so helps provide more reusable and 
maiHttOnaile pr^^gfrnm- 

Programs contain two major paths: a forward path that does 

the work and a reverse path that rolls back the work when 
the program detects errors. Typically, these paths are so 
tightly bound together that both paths are difficult to read. 
Code that is difficult to read results in code that is difficult 
to write, debug, enhance, and reuse. 

For example, in object-oriented programming, you cannot 
reuse objects as much as you might want, primarily because 
the objects are t^htly bound together at the error-handling 
level. Many times, error code even giv^ clues about how a 
program implements an object. 

The solution is to handle errors in programs as you would 
in a database-transaction recovery mechanism. A database 
transaction is a unit of woric that involves one <xe more oper- 
ations on a database. FVn: example, the operation of inserting 
data into a database could be a transaction if it's the only 
operation performed. If you combine the insertion with an 
update, the program considers both operations as one trans- 
action. In a database transaction, the transacti(m either exe- 
cutes in its entirety, or, if an error appears in any of its oper- 
ations, the transaction totally cancels as if it had never 
executed. If an error appears, the program automatically 
rolls back all work to the beginning of the transaction. 

When a development team first introduces transaction error 
handling to a project, many engineers resist it because it 
requires the removal of IF statements after calls to functions. 
Engineers also beUeve the technique makes debugging more 
difQcult. However, after seeing how much easier it is to read and 
write transaction error-handling code, the resistance fades. In 
addition, transaction error handling decreases debugging time 
to a little less than that of the traditional method. The reason 
for this decrease is probably that transaction error handUi^ has 
less embedded error-handling code, causing delects to stand 
out more. Also, when you add error-handling code, you do so in 
the structured way that most engineers like to work — a method 
that disturbs very little of an already-debugged program. 

BljjgB software listings in this article are available on fDN's computer 
BqBI bulletin-board system. Phone |617) 558-4241 with modem settings 
300/1 200/2400 8,N, 1 . Access /freeware SIG and specify (r/eod 
^HHB option followed by (kfeyword search for "MS #769." 



Software dev^opers are often dismayed at how difficult 
eranmerdal programs are to maintain and design, compared 
with programs they developed in school, "nie reason for this 
may be that the programs students develop in school are 
"toys" that assume perfect inputs and that the hardware has 
unlimited memory and disk space. In addition, most software 
engineers have very little formal training in error-handling 
methods. Typically, software dei^opera learn error han- 
dling by example or by trial and error, and they use the tra- 
ditional error-handling model: Check for an error, find an 
error, and return an error code. 

Many formal design processes, such as structured analysis 
and structured design, recommend that developers ignore 
errors during design because such errors are an implemen- 
tation detail. However, this "minor" detail can take up to one- 
third of the code in commercial programs. This code appears 
not just around algorithms but directly in the middle of the 
algorithms. The resulting programs are difficult to read, 
debug, and reuse. 

In addition to existing design methodologies, such as 
structured analysis and structured design, is exception him- 
dling, or error handling. This programming style separates 
most of the error-handling processes from the main algo- 
rithms. Error handling C(HiQ>rises four main parts: detection, 



Fig 1 — In traditional error-handlina program flow, the forward potli 
does the work of the program, and the reverse path does the enw 
hondbg. ErnHbniARg code iqqwars thfwighort tfao oig^^ 
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correction, recovery, and reporting. The main focus of this 
article is error recovery. 

In this context, the term "error" does not refer to a defect 
but to an exception that an algorithm cannot handle. A 
"defect," on the other hand, is an error that strains the design 
limits of an entire application or a system. For example, many 
algorithms assume that there is unlimited memory. Insuffi- 
cient memory for the algorithm to complete successfully con- 
stitutes an error, and you must design the whole application 
to handle these out-of-memory errors. A defect occurs when 
an application that does not handle these errors causes a pro- 
gram to halt or to behave in an undocumented way. In oth^ 
words, whether something is an error or a defect depends on 
what level of the software hierarchy you are observing. 

Mixed forward and reverse path problem 
Fig 1 shows the two msgor paths in commercial programs. 

The forward path does the work for which a program is 
designed. The reverse path is the error-handling code that 
keeps the forward path working correctly. It does this by 
detecting and fixing problems and rolling back partially com- 
pleted work to a point at which the algorithm can again con- 
tinue forward. 

An intermediate function in a program has to stop what it 
is doing in the middle of the algorithm because the program 
called a function that cannot complete its task. This can lead 
to "tranq) errors," a term similar to the "tramp-data" term 
of atructored analysis and structured design (Ref 1). 

Tramp errors in functions do not directly relate to the cur- 
rent function but are the result of a real error occurring in a 
lower-level function. For example,^nctiow A() calls function 
B(). Function B() needs some memory, so it calls the mallocO 
memory-allocation function. The mallocQ function returns 
an out-of-memory error. This is a real error for the mallocQ 
function. Function BO does not know how to get more mem- 
ory, 30 it has to stop and pass the error back to function A(). 



Fig 2 — la transaction error-haaiiiing pragran flow, oiriy error- 
detectioa codo for red omrs raoHiias, m awst of tho errai^t^^ 
tion and recovery code dastm ofoond the beginoiag and eRd of Ike 

transactions. 



From the perspective of function BQ and probably function 
AO, an out-of-memory error is a tramp error. 

Tramp errors prevent functions from becoming "black 
boxes." Pbr example, fimetion AO (above) now knows some- 
thing about how function BO works. In other words, tramp 
errors form a part of error recovery — not error detection — 
because if the program could immediately correct real 
errors, tramp errors would not occur. Because of tramp 
errors, almost every function has to handle errors that lower- 
lewd functions generate. This buck-passing can cause tight 
data coupling, which makes code reuse more difficult. 

Unreadable code and poor reuse 

Mixed forward and reverse paths and tramp errors com- 
bine to obscure the main forward path of the program, which 
is doing the real work. The correction and recovery parts of 
error handling are the main OMOs that obsenre t^e code. Most 
of the code for detection and reporting can be in separate 
functions, so these components of error handling play less of 
a role in obscuring code than do the other two. 

You can solve tlie problems of unreadable code and poor 
reuse by separating the forward and reverse error-process- i 
ing paths and by using context-independent error codes. This 
method of error handling is very similar to the way databas- j 
es handle error recovery. Transactions cmitrol the rollback ' 
process when a group of database operations cannot complete 
successfully. 

The traditional defensive way of programming is to 
assume that a function may have failed to complete its task, 
resulting in a lot of error-handling code to check for the 
errors and to roll back partially completed work, as Fig 1 
shows. Now, assume the reverse — ^that returning functions 
have successfully completed their tasks. In this scenario, if 
the function or one of the functions it calls has errors, the 
function passes processing control to a programmer-defined 
recovery point. In other words, the programmer defines 
transaction points so that if there are any problems, the work 
rolls back to those points, and the processing again proceeds. 
With this approach, you do not need to check for errors after 
each function call, and tramp error-detection code does not 
clutter the forward path. 

Context-independent error codes provide more informa- 
tion than just an error number. They also provide information 
such as which function generated an error, the state that 
caused the error, the recommended correction, and the error 
severity. This information allows the program to correct the 
error in a location separate from the forward processing path. 

Programmers usually encode contracts of errors for error- 
reporting functions. For example, error contexts may include 
the names of the program, the function, the error type, and 
the error code. The program saves these parameters to 
report later. However, programmers rarely use sophisticat- 
ed encoding schemes because traditional error handling 
already knows the context of the error: Checking occurs 
right after a call to the offending function. 

With transaction error handling, the recovery process is 
separate from the forward processing path, necessitating the 
use of context-independent error codes. This may involve 
creating unique error codes across a whole application or sys- 
tem (with the codes bound at compile time). An alternative 
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would be to assign code raoiges wt oth^ umque identifiers to 
fuactaons at runMine. 

Code readability and reuse 

The transaction error-handling approach makes programs 
easier to read because the reverse-processing paths are visu- 

ally separate from the forward-processing paths. This 
method makes possible creating some general error-recov- 
ery interfaces so that functions (modules or objects) connect 
only loosely at the error-handling level. This loose connection 
is possible because the iiiem axe few^ trMop errors to con- 
trol the recovery process, and the j^gram needs to liaadle 
only the real errors. 

Two methods you need for building a transaction error- 
handling library are transaction-control and transaction- 
data management. Transaction-control management 
requires some language support to implement the mecha- 
nism that controls error recovery. For example, languages 
like Hewlett-Packard Go's Pascal-MODCAL have a 
"try/recover" featia® that em support a tiran^tion spfor- 
handling style. 

For other languages, you must use a "global-goto," or 
"multithreaded," feature, which allows a lower-level function 
and all other functions above it to exit to a point you define in 
a higher-level function without passing error-code flags 
through all the other functions. In C, you do this with the 
setjmp and longjmp library routines. The setjmp function 
saves its environment stack, and longjmp restores that envi- 
ronment. The listii^, which are written in C, show how 
these functions work. 

The material in Ref 2 details the new C++ exception-han- 
dling feature, which provides an excellent foundation for a 
transaction-based error handler. The material in Ref 3 also 
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Fig 3 — A try/recover sMNnmiA defines error-recovery code that 
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describes how to add C++ error-handling functions to regu- 
lar C ^ograms. However, overuse of transaction error han- 
dling can lead to code that is just as cluttered as the tradi- 
tional error-handling style. You must design transaction 
boundaries for objects with the same care that ym wOvM to 
design an object's interface. 

If a language is missing a global-goto or multithreaded fea- 
ture, use macros or other "wrapper" functions to build recov- 
ery processes that are mostly invisible. Wrapper functions 
and macros add functionality to functirais that you caiimot 
change, such as library functions. 

In building a tran^^cSft-handling package, you might 
want to give it the following features: 

• Allow nested transactions by keeping the transactions' 
beginning points on a stack. 

• Allow functions to share a common transaction stack. 



Listing 1 - Traditional error-handling style 



read.e - H«a4 a biimxy fomuit:c«d £il<e 
Sfais progma rwids aoA prints a biouy file 1^ 
following structure: 



Record type code (Tha last im&oxA tax 
Size Stm^T of c^racters in Ha? 
Msg CO 3048 c&aracters 
Rttcozvl typm oode 
Sim 



a value of 



/* 
I* 
/* 
/* 
/* 
/* 
/* 
/* 
/• 
/* 
/* 
/* 
/* 

#define aBxit:Ei!^(pHsg, pBrr) 
#deflne aRetErr (pHag, ^rr) 

tV^edef at:ruct { 
long Type; 
inc Size; 
} aPileHead; 
/* 
/* 
/* 
/* 
/' 
/' 
/• 
/* 

mainO { 

int Err; 
FILE * laPile-; 

if {(laFiXe - fop«("filB.bin", "rb*)) — HBXi*) { 

aK arl fB - ra rCBrgor; Could mw; ops^x file. bin-, 1); 



Porwa^ Al^ritlua: 

Main 

1. Open Che file. 

2. Call the Read process. 

3. Close Che file. 



1 

If ((a 



' aiI#ad(ZnFlls) ) >- o> [ 

aSxitErrt "Error; While reading: file. bin", 21; 



(fclosednFile} { 

a&KitErr( "Error: 



Clpsingj file.Mn", 9) 



}/• i^int) */ 



P&rward AlgoriClan e:!^eimeid: 



Read Prwess 

1. Read the Type and Size vitliuss. 



2. If Type = 0, exiti 

3 . Read Size number of characters into the 

Mag variable. 

4 . Print the Msg. 

5. Go CO step 1. 

aRead tpHandle) 

FILE * pHandle; 



*/ 

*/ 
*/ 
*/ 
*/ 



Err, 
Msg; 



:Lnt 

char * 
aFlltffead 



if {{Msg - (char *) 

altecBrr ( '"^^t^-i 

RecHimi - OL; 

4^1e CD { 

if (fseekCpHandle, RecMura, 3EEK_SET) < 0) { 
^ aRetErr("Error: in fseek", «) ; 

W = fread({char *) £RecBe»i, 'ai2eof {^ileHeadl , X, 
if (N < 0) { 

aRetErr ("Error: in f rrad" , S) ; 
} else if (H J- 1) { 

^ aRetErr ( "Error: short fread", S) ; 

if [Rec^ad.Type « OL) f 

ret^i»(e); /* EOT */ 

If (SseHead.size) { 

if {(» « fread(Msg, RecRead.Size, 1, 
pHandle)} <. o) { 

aRetErr (*Brror! in fread", 7); 
} else if m 1- 1) { 

^ aRetErr ("Error: short fread", 8); 

if ((Err = aPrinttMag, 

RecHead.Size) ) ;= 0) ( 

aRecErrCError: in aPrinC", Err) 



pKanfte) ; 



RecJRim » RecKuffl + RecHead.Size ♦ sizeof (aFilsHead) ; 



} /» iateadO */ 
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Listing 2 - Transagion error-handling method 



/* read.c - Read a binary forntttvd fiXm •/ 

/* This program reads and prlafis ft hiiusty tUm th*t haa tbe */ 

/* following acruccurei */ 

/• V 

/* RBCord type cods VOm laat record has a nJjw ot 0) */ 

/* SlzeNuodaar of duucaetftrs In Nag */ 

/• Hsg to 3040 f^ftxaetors •/ 

/* Record t^^o code */ 

/* Size •/ 

/* Msg */ 



# include ' erpub . h* 
ft incl ude - epub . h' 
Cypedef struct ( 

long Typof 

inc Slaej 
} aFileHeadi 
/* 

/* Porvard Algorithm t 

/« 

/• Main 

/• 1. open tm tils. 

/* 2. Call thft Read prooua. 

/* 3. Close the file, 

/• 

nainO { 

PILE ♦ InPile; 
erRecOn - 1 ; 

if (erSetO) ( /* Transaction rollback point: •/ 
printf ("Error: *d in function: %B\n", erErr, 

erPun) ; 
erUnset ( ) ; 
exicd) ; 
,} /* Sad Rftcovsry Mccion */ 



• Allow functions to define their own transactions witii a 

common transaction stack, or allow functions to de&ie 
their own transaction stacks for special cases. 

• Define special transaction points to handle errors in com- 
mon categories. (For example, abort the whole program, 
restart the whole program, dose all files and restart, 
close current file and restart, and release all mmory not 
needed and restart.) 

• Have the transaction error handling torn on and off. 
(When transaction error handling is off, a function 
returns error codes in the traditional way.) 

• Define expected errors for some functions by masking 
out the needed errors. (You can simulate this feature by 
turning off transact!^ error handling, but then you also 
have to manage un^cpeeted earrtm.) 



Transaction-data management 

Recovery involves more than just roUii^ back functions to 
undo some intermediate worii. It may also involve releasing 

^nneeded memory or changing global variables back to the 
values they had at the beginning of the transaction. 

You can best manage memory using a mechanism similar 
to the mark/release memory feature in some implementations 
of Pascal. The maric/release procedures allow dynamic alloca- 
tion and deallocation of memory in an executing Pascal pro- 
gram. The C functions mallocQ and freeO, along with a stack 
of pointers to track the allocated memory, provide the best 
features for allocating and freeing memory. With these fea- 
tures, you can call a mark function just before the program's 
transaction starting point to mark the current stack point. If 
a longjmpO goes to this recovery point, the release function 
is called to firee any memory allocated after the mark point. 

To remove pointers from the mark/release stack, you need 
a commit function at the end of a program transaction. The 
commit function indicates the successful completion of a 
transaction in the database context. You must also consider 
nested transactions, however. A simple solution would be to 
have each transaction keep its own mark/release stack. 
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aReadtInFila>i, 
fcloBa(XnFll«ii« 
erUnaatO ; 
} /* awLaO */ 

/* Forward JOgorltlw ^MlWtt */ 
/• •/ 
/* Read Proceas*/ /* 
X. Read Che Type aod Sise values. */ 
/* 2. If Type - 0, «Klt. */ 

/• 3 . Read Size uiH w r oC eharacters into tlia */ 

/• Meg variabi*. */ 

/• -4. Print the Mag. */ 
/* 5. Go to step r. •/ 

/• •/ 
lat aSMdCvOiBBdle) 
^ FZU * pBandle; 

char • Msg; 

long RecHum; 

aFileHead RecHead; 

Hog - (char *) mai3ao4 »im i fr ,a al < 

RecMum - OL; 
Wblle (1) { 

faeek (pHandle, RecNum, SEEK SET) f 

£read((char -) &RecHead, aizeof (aMlaBaad) , L, pHaadla) ; 

if (RecHead. Type — OL) ( 
return;/* EOF •/ 

) 

if (RecHead. Size) ( 

freadUtag, RecHead. Size, l.pHandlel ; 
aPrintOleg, RecHead. size) ; 

IHu— - amemm * «ecae^.Siza * elzeaf (erlleBead) i 

) /> aMadt) •/ 



Listing 3 - Macros and global data structures 



You can roll back global and other static variables with a 
strategy similar to the one in the memory-management 
problem. Just before a transaction's beginning point, the pro- 
gram saves on a stack the states of all the globals that might 
change. This strategy allows you to nest transactions. 



Context-independent error codes 

The traditional error-handling style of checking error 
codes after each function call automatically gives errors a 
context. The transaction error-handling style provides this 
context information in another way. The biggest challenge in 
transaction error handling is that error codes alone are not 
very useful. For example, "97" could be the letter "a" in 
ASCII code, the digits "6" and "1" in BCD format, index 97 
in a message array, the 97th error, an out-of-memory error, 
a disk-full error, a divide-by-zero error, or another error. 

To decode an error code, a program must know the source of 
the error. Some information that the program may save when 
an error occurs includes the machine name, the p:t>gram name. 



J. 



I* erpub. h - Error Recovery Pttbllc Include file */ 
#include<set j mp . h> 
I* Private VarlcUilea */ 
#dBf laa vMaucBmr 5 
jmp buf vBisv[vMaxEnv] ; 
int~ 
vLevel - -1; 

/♦ Public Variables ♦/ 
#deflne cerFunNameLen 32 

#define erSecO aet jmp (vEnv('t~»Tl<evel] > 

#dtt£ine erUnsetO - -vLevel 

Maflne erRollBack (pFun, pErr, pRet) \ 

3tmcpy (erFun, pFun, cerFunNameLen}; \ 
erFun [cerFunNameLen-1] » \0;\ 
erErr = pErr ; \ 

if (erRecOn vLevel >■ 0) { \ 

longjmp ( vEnv [vl.evell , pErr) ; \ 
) else { \ 

return (pRet) ;\ 
} inc erErr ^ ; 
char erFun [cerFunNameLea] j 
int erRecOn « 0; 
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the process number, the module name, the function name, and, 
of eourse, the error code. The program needs to send tibis inioe- 
mation only when it must roll back a transaction. 

The amount of information that the program saves 
depends on the location of the transaction-recovery point and 
on the runtime environment. For example, a client-server 
application may need more information tiian does a simple 
PC application. Each recovery point can usually find higher- 
level context information fairly easily. For example, the 
names of the machine, program, module, and function can 
easily pass down to a lower-level recovery point. However, a 
program cannot collect lower-level context information 
because, by the time the program gets down to that level, the 
function that had the error would no longer be active. 

You may want to consider the following points when imple- 
menting a transaction error-handling scheme: 

• Put the rollback points, if any, at the beginning of func- 
tions. 

• Put error detection and default substitution at the begin- 
ning of functions. 

• Put some error-detection code in the middle of functions 
to check intermediate values. 

• Put error-detection code at the end of faasMsim to vidi- 
date the results. 

• Do not put error-handlij^ code for managing rollbacks in 
the middle of a fiinction. 

Traditional error-handling style 

Listing 1, which reads a binary formatted file, is coded 
witii a common error-handling st^e. The code would have 

been more cluttered without the aExitErrf) and aRetErrQ 
macros to manage the error reporting and recovery. Listing 
1 uses the simple error-recovery process: Detect error, 
report error, and exit. However, notice Iu>w much error-han- 
dling code is mixed in with tiie algorithm. 

Listings 2 through 5 show an implementation of the trans- 
action error-handling style. Listing 2 performs the same 
function as the program in Listing 1 but uses the transaction 
style of error handling. The functions erSet, erUnset, and 
erRoUBack provide the error handling defined in the include 
file erpub.h. Listings 3 through 5 show the support functions 
for the transaction error-handling method. In the main body 
of the algorithm, the code following the recovery sections is 
clearer than that in the traditional error-handling example, 
and there is no error-handling or recovery code mixed in 
with the algorithm. 

However, there are some shortcomings in the support 



modules. Pbr example, most of the macros should be func- 
tions, and the program should save the vEnv values in a 
linked list. Some engineers point out that the transaction 
implementation of read.c is not really shorter than the tradi- 
tional implementation of read.c because the error-handling 
code simply moves from read.c into the support functions. 
But that is exactly the goai to remove the error-handling 
code from most functions and encapsulate the emnr-haiuiling 
in common shared code. 

The include file epub.h contains wrapper macros that cause 
the program to call the appropriate transaction error-han- 
dling functitsts instead of lie standard lilowry ftmetiffli. Pbr 
example, wbea invoking the standard fnnctiaa fdoge, the pro- 
gram actually calls the function eClose. 

lAating 3 defines macros and global data structures that 
form a crude error-transi^ticHi manager. The macros per- 
form the following opeiateaii: 

• erSet. This macro adds ardlback point to the vEwo (envi- 
ronment) stack. 

• erUnset. This macro remmw the top roDiads. p<nnt from 
the vEnv stack. 

• erRolIBack. This macro saves the function name and 
error code in a global area (erFun and erErr), and if the 
erRecOn flag is true, control passes to the rollback point 
defined on the tsp et tJie vSm stack. If erRecOn is false, 
erRolIBack simply returns the usual error code. 

These macros are for illustration only. Thus, there are no 
internal checks for problems, and you should define the glob- 
al data structures as static values in a library module or cre- 
ate a structure to edleet them. This structure is passed to 
each of the transaction error-handling functions. 

Listing 4 contains wrapper macros that cause the pro- 
gram to call the functions in the file e.c in place of the stan- 
dard library functions. The functions in e.e behave the same 
as the standard library functions, but if the error transaction 
manager is on {erRecOn is true in erpub.h), control passes to 
the last defined rollback point, rather than just returning the 
same error code as the associated standard library function. 

Using these wrapper macros makes it easier to add trans- 
action error handling to old programs, but if you want to 



Listing 5 - yNm?ik funqions 



/* e.c - Error Library Wr«{^r Funccioos (only a few are 

shown here) */ 
#define vlnE 
^include "epub.h" 
void * «M*Xloc(pSixe) 



} /• 
size c 



} /* 



void * Hem; 

if ((Hem - malloc(psize) } HULL) { 

^ erRollBaek("mailoc", ceOucOfMem. Mem) ; 

recum (Mem) ; 
eMailoc •/ 

eRead[pPcr, pSize. pNItem, pstream) 

char * pPcr; 

3ize_t: pSize, pHltwn; 

FILE~* pSt:ream; 

sixe_t: Hum; 

Hum « f read (pPtr, pSiie, pNltem, pS Cream ) ; 
if (feof (pstream) ) { 

erRolIBack ("f read". ceEOF, Hum); 
} else if (Niim <- 0) ( 

erRollBack("fread", ceRewffirr, Hum); 
} else if (Htm < pMI&aa) { 

eraollBackCfrsad", ceReadSbore , Ibim) ; 

return (Hum) ; 



Listing 4 - Wrapper macros 



/*epub.h - Error Library Wrapper ."Macros loniy a :ew are 

shown here) •/ 
#define ceEOF l 
Sdefine ceOucOfMem 2 
{(define ceReadErr 3 
^define ceReadShorc 4 

ttifndef vinE 

Mefine £clo8e tpSCreui) eCloae (pStrem) 

Mefine fopenipFileHame, pTypei eOpentpFilsMaae, pType) 

tdefine fread(pPCr, pSize, pNXtem, pstream) \ 

eReadlpPtr, pSize, pHZCen. pStT«ui) 
fidef ir.e f seeic IpStream, oO££Mt . [irrrllime) \ 

eSeek Ipscream. pOffaeC, pC'rtHanfti 
ttdefine malloc ipSizeJ eHalloc (pSize) 

ttendif 
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moRHMDum 



make the error-handling process more visible, have the pro- 
gram call the functions in e.c directly instead of the standard 
library functions. The file in Listing 4 is also a good place to 
define context-independent error codes. 

The file in Listing 5 contains the implementations of the 
wrapper macros in epub.h. Listing 5 shows only two of the 
functions. These functions behave exactly like the standard 
library functions Avith the same name because they call the 
standard library functions. For more flexibility, a real error 
transaction manager might allow you to define the error 
codes that determine wheth^ a rt^Kmdk occurs. 

So far, only small programs and enhancements of existing 
programs have used the transaction error-handling tech- 
nique. But, its features — greater code reuse, greater code 
supportability, and better quality code — may make it more 
widespread. Just as you can separate the functional part of 
algorithms from user interfaces (client/server models), you 
can also separate error handling from the functional algo- 
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